[release/10.0] Add loopback addresses to the development certificate #64584
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rbhanda
added
Servicing-approved
wtgodbe
approved these changes
Dec 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #64431 to release/10.0
/cc @danegsta
Add loopback addresses to the development certificate
Adds 127.0.0.1 and ::1 to the development certificate SAN
Description
Adds the IPv4 (127.0.01) and IPv6 (::1) loopback addresses to the development certificate Subject Alternative Names for the dev cert. This will allow the certificate to be used to secure services such as a SQL Server or Azurite container where there are client restrictions that require accessing the service by IP address instead of hostname.
Fixes #64430
Customer Impact
Aspire has started adding APIs to configure local services that aren't ASP.NET Core based to take advantage of the development certificate to provide TLS during local development, but we've found a couple cases where clients don't properly handle the
localhostdomain for local traffic and instead require using a loopback IP. The SQL Server connector is the worst problem; it specifically resolveslocalhostto the PUBLIC IP for the machine, not the loopback IP. This requires us to connect to local SQL Server containers using127.0.0.1(or::1). The second case is the Azure Storage SDK, which treats ANY hostname (includinglocalhost) as an external custom storage domain; the only way to connect to a local emulator in a .NET app is to use127.0.0.1.This change allows us to enable TLS for the SQL Server container image and the Azurite storage emulator using the development certificate and be compatible with the quirks of the client libraries that force using IP addresses for loopback traffic.
Regression?
[If yes, specify the version the behavior has regressed from]
Risk
[Justify the selection above]
Verification
Packaging changes reviewed?
When servicing release/2.3